ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98b.txt/000102_icon-group-sender _Mon Jun 22 16:44:52 1998.msg

Internet Message Format | 2000-09-20 | 8KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id QAA22862
    for <[e-mail]>; Mon, 22 Jun 1998 16:44:51 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA23562; Mon, 22 Jun 1998 16:44:41 -0700
Date: Mon, 22 Jun 1998 16:39:26 -0500
Message-Id: <[e-mail]>
From: Clinton Jeffery <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> ([e-mail])
Subject: Re: using Icon for database application
Reply-To: [e-mail]
Errors-To: [e-mail]
Status: RO
Content-Length: 7013

[Frank Sergeant offered a discussion of a large Clipper application that
he is maintaining, followed by a number of Icon questions.]

Hi Frank,

I'm glad you liked the Linux Journal article on Icon.  While I disagree with
Gordon Peterson's answers to your questions on many or most points, he did
say several things that are very true; you will have to figure out for
yourself which of his comments are relevant for your application.  I suspect
Gordon has more experience than I with xBase languages (although I did
program-for-hire in dBase III and Foxbase).  I've done a lot more Icon
programming than Gordon, who frequently posts about Snobol in the Icon
group, bless his heart!

>   Icon questions (or comments)
>    1. How do you think all this fits with Icon?

Icon isn't a special-purpose database language.  Its built-in types are
designed for flexible data manipulation in main memory.  If that's what
you want to do, you are all set; if not, you should look for a database
language, or think about connecting Icon to a third-party database engine.
There's more on memory requirements in your question 9 below.

>    2. I gather Windows Icon can make a normal looking
>       Windows application (rather than a Motif-ish
>       application) and that I probably could figure out
>       how to do this by reviewing the source code for Wi.
>       Does that sound reasonable?  Would _Graphics
>       Programming in Icon_ help?

Well, you shouldn't have to learn it by studying source code.  Both the
on-line reference and an appendix in "Graphics Programming in Icon" discuss
these functions, which are quite simple.

>    3. How fast is an Icon application?

In your hypothetical client/server architecture, the database engine
performance will be your bottleneck.  Icon's graphics are plenty fast enough
for 486 clients, but Icon would not be suitable for the server software
unless either (a) enough main memory was available to fit all the indices
and preferably the data as well, or (b) you extended Icon to access a
third-party database, such as Postgres or mSQL.

>    4. How big would the .EXE file be?
       How does .EXE file size grow after [the 200/300K interpreter]?

It grows at a moderate rate :-) depending on how effectively you are using
the built-in features.  The virtual machine is by nature higher-level and
potentially more compact than many languages, but if you write many thousands
of lines of Pascal-like (or xBase-like) code, it will be huge.

One wart I know of at present: if you use tons of different record types you
get penalized (this is true, for example, of the Motif-like portable widgets
in the Icon Program Library).  I thought a student had fixed this for me,
but his "field table compression" has some bugs that need fixing before we
turn it on and leave it on by default.

>       Currently our .EXE is about 850K, so I can live with that size,
>       but would prefer smaller.

I think the Icon program would be larger, unless your rewrite substantially
reduces the number of lines of code to exploit Icon's built-in features.  If
you just translated xBase line-by-line into Icon the result will be huge.
Clipper is (was?) a fine commercial-quality product.

>    5. Is a sockets interface only available for Unicon or
>       is it also available for Wicon?

Ah, its time for some vaporware.  Sockets are only available on Unix at the
present time.  I've merged Unicon into my main source tree so that I can
start porting it to Windows, but I have to wrangle with some other problems
in Icon 9.3.2 before I take that on.

>       If sockets are not built in to Icon, how hard is it to make
>       calls to the Win32 system?  How about to routines
>       produced by MSVC or Borland C?  Perhaps I could
>       write the socket access routines in C and call them
>       from Icon?

I keep getting nibbles, but so far no one has volunteered to implement this
kind of access.  You can get the Windows Icon source and make such
extensions yourself, and if you build something really useful I'd certainly
like to incorporate it into the main public domain Windows Icon
distribution.

>    6. So far I haven't been able to track down Idol.  A url or two for
>          Idol on the web site seemed to give an "invalid" message.
>       it seems I should consider using Idol if I use Icon, right?

My apologies; there was a reorganization that left a bad symbolic link.
The main Idol web site is now www.cs.utsa.edu/research/idol/ and I am
in the process of packaging a release of Windows Idol.  You should consider
using Idol if you want to write object-oriented applications or have a large
complex application with many user-defined types.

>    7. I currently make extensive use of Clipper's "ragged arrays".
>          These are essentially lists where the elements can be of any
>          type including other lists.  It looks like Icon's lists would
>          just drop in and work the same.

Yes, or better.

>    8. The current app is about 150,000 lines (over 100 source code
>          files).  How does Icon handle applications of this size?

Icon is generally tuned for speed, rather than to minimize space
requirements.  I've heard reports of Unix Icon programs in the million line
range, but haven't seen a Windows Icon program in the 100K range yet.  My
impression is that Windows manages virtual memory much worse than UNIX or
Linux.  On old 486's with 8MB of memory you may run into terrible problems
unless you split the application up into a thin "client" program that can
access a server with more muscle.

>           I think the app is currently more complex than is required.
>           All we do, really, is keep track of, display, modify various
>           lists --  lists of doctors, patients, insurance companies,
>        charges, paygments, and such.  (How hard can it be?)

This is generally vastly easier in Icon than in an xBase language.

>    9. The data, ignoring index files, probably runs 2 to
>       10 MB in most offices.  At the larger sizes, much of
>       the data is relatively inactive and could be rolled
>       out to archives.  On a modern machine, all the data
>       would fit in RAM.

I heartily recommend memory-based databases!  Memory is cheap.
The server should have lots of memory.

>       10. I have been very impressed with Bertrand Meyer's
>       _Object Oriented Software Construction_.  Can anyone
>       comment on the differences between Eiffel and Icon,
>       that is, why I might prefer Icon over Eiffel, etc?

Icon is dynamically typed, offers a lot more flexibility, and has a much
higher-level set of built-in data structures and operators.  Eiffel is a
very good object-oriented systems language geared more for multi-programmer
efforts that might otherwise be written in C++ or Ada.  You write a lot more
lines of code in Eiffel to do the same work.  Eiffel may run quite a bit
faster; I am not sure how much.

Cheers,

Clint Jeffery, [e-mail]
Division of Computer Science, The University of Texas at San Antonio
Research http://www.cs.utsa.edu/research/plss.html